Zum Hauptinhalt springen

Übung: API-Endpunkte mit dem Post Agent nutzen

Was du in dieser Übung lernst: Du baust Workflows in 42°OS, die eine echte REST API ansprechen — Daten abrufen, anlegen, ändern und löschen. Du konfigurierst den Post Agent für jede HTTP-Methode und siehst im Run Inspector wie Requests und Responses aussehen.

Die API für diese Übung​

Für alle Aufgaben steht eine öffentliche, persistente REST API bereit. Kein API-Key, keine Registrierung — du kannst sofort loslegen.

Base URLhttps://69cde52533a09f831b7c9fa5.mockapi.io/api/v1
Ressourcecontacts
EndpunkteGET /contacts, POST /contacts, GET /contacts/:id, PUT /contacts/:id, DELETE /contacts/:id

Jeder Kontakt hat folgende Felder:

{
  "id":        "1",
  "createdAt": "2026-03-28T14:22:00.000Z",
  "name":      "Maria Schneider",
  "company":   "Müller GmbH",
  "updatedAt": "2026-03-28T14:22:00.000Z",
  "email":     "maria.schneider@example.com"
}
Hinweis

Die API ist für alle Teilnehmer gemeinsam sichtbar. Wenn du Kontakte anlegst, änderst oder löschst, sehen das auch andere. Das ist gewollt — es simuliert eine echte, geteilte Datenquelle.

Teil 1: Kontakte abrufen (GET)​

Aufgabe 1 — Alle Kontakte abrufen​

Lege einen neuen Workflow an, z. B. API-Übung — Kontakte lesen. Baue folgende Struktur:

[ Manual Message Agent ]  →  [ Post Agent ]  →  [ Human Task Agent ]
  Trigger                     API-Abruf          Ergebnis anzeigen

Post Agent konfigurieren:

{
  "post_url": "https://69cde52533a09f831b7c9fa5.mockapi.io/api/v1/contacts",
  "method": "get",
  "content_type": "json",
  "emit_messages": true,
  "output_mode": "clean"
}

Starte den Workflow über den Manual Message Agent und prüfe im Run Inspector:

  • Welchen status hat die Antwort?
  • Wie sieht der body aus — ein einzelnes Objekt oder ein Array?
  • Welche Felder hat jeder Kontakt?

Aufgabe 2 — Einen einzelnen Kontakt abrufen​

Wähle eine id aus der Kontaktliste von Aufgabe 1. Baue einen zweiten Post Agent (oder ändere die URL) für einen gezielten Abruf:

{
  "post_url": "https://69cde52533a09f831b7c9fa5.mockapi.io/api/v1/contacts/1",
  "method": "get",
  "content_type": "json",
  "emit_messages": true,
  "output_mode": "clean"
}

Vergleiche die Antwort mit Aufgabe 1:

  • Was ist der Unterschied zwischen der Antwort von /contacts und /contacts/1? (Array vs. Objekt)
  • Was passiert, wenn du eine ID verwendest die nicht existiert, z. B. /contacts/99999? Welcher status kommt im Run Inspector zurück?

Teil 2: Kontakt anlegen (POST)​

Aufgabe 3 — Neuen Kontakt mit eigenen Daten anlegen​

Lege einen neuen Workflow an, z. B. API-Übung — Kontakt anlegen. Baue folgende Struktur:

[ Web Form Agent ]  →  [ Post Agent ]  →  [ Human Task Agent ]
  Eingabe: Name,         API-Aufruf        Ergebnis anzeigen
  Firma, E-Mail

Web Form Agent — Richte drei Textfelder ein:

BezeichnungBeschriftung
nameName
companyFirma
emailE-Mail

Post Agent konfigurieren:

{
  "post_url": "https://69cde52533a09f831b7c9fa5.mockapi.io/api/v1/contacts",
  "method": "post",
  "content_type": "json",
  "payload": {
    "name":    "{{ name }}",
    "company": "{{ company }}",
    "email":   "{{ email }}"
  },
  "emit_messages": true,
  "output_mode": "clean"
}

Öffne das Formular, gib deine eigenen Daten ein und schicke es ab. Prüfe im Run Inspector:

  • Welchen status bekommst du? (Erwarte 201 — Created)
  • Welche Felder hat der neue Kontakt in der Antwort, die du nicht mitgeschickt hast? (z. B. id, createdAt)
  • Merke dir die id des neuen Kontakts — du brauchst sie in den nächsten Aufgaben.
Liquid-Templates

Die doppelten geschweiften Klammern {{ name }} sind Liquid-Templates. Sie werden beim Ausführen durch die Werte aus der eingehenden Nachricht ersetzt — in diesem Fall die Formular-Eingaben. Das kennst du bereits aus Kurs 1.

Teil 3: Kontakt aktualisieren (PUT)​

Aufgabe 4 — Firmennamen ändern​

Lege einen neuen Workflow an, z. B. API-Übung — Kontakt ändern. Baue folgende Struktur:

[ Web Form Agent ]  →  [ Post Agent ]  →  [ Human Task Agent ]
  Eingabe: ID,           API-Aufruf        Ergebnis anzeigen
  neue Firma

Web Form Agent — Richte zwei Textfelder ein:

BezeichnungBeschriftung
kontakt_idKontakt-ID
neue_firmaNeuer Firmenname

Post Agent konfigurieren:

{
  "post_url": "https://69cde52533a09f831b7c9fa5.mockapi.io/api/v1/contacts/{{ kontakt_id }}",
  "method": "put",
  "content_type": "json",
  "payload": {
    "company": "{{ neue_firma }}"
  },
  "emit_messages": true,
  "output_mode": "clean"
}

Gib die id aus Aufgabe 3 und einen neuen Firmennamen ein. Prüfe im Run Inspector:

  • Welchen status bekommst du?
  • Hat sich nur die Firma geändert, oder auch andere Felder (z. B. updatedAt)?

Beachte: Die id wird hier direkt in die URL eingesetzt — {{ kontakt_id }} wird per Liquid durch den eingegebenen Wert ersetzt. So baust du dynamische URLs für Einzelressourcen.

Teil 4: Kontakt löschen (DELETE)​

Aufgabe 5 — Deinen Kontakt wieder entfernen​

Lege einen neuen Workflow an, z. B. API-Übung — Kontakt löschen. Baue folgende Struktur:

[ Web Form Agent ]  →  [ Post Agent ]  →  [ Human Task Agent ]
  Eingabe: ID             API-Aufruf        Ergebnis anzeigen

Post Agent konfigurieren:

{
  "post_url": "https://69cde52533a09f831b7c9fa5.mockapi.io/api/v1/contacts/{{ kontakt_id }}",
  "method": "delete",
  "content_type": "json",
  "emit_messages": true,
  "output_mode": "clean"
}

Lösche den Kontakt den du in Aufgabe 3 angelegt hast. Prüfe im Run Inspector:

  • Welchen status bekommst du?
  • Was passiert, wenn du dieselbe ID ein zweites Mal löschst?
  • Geh zurück zum Workflow aus Aufgabe 2 und versuche den gelöschten Kontakt per GET abzurufen. Was kommt zurück?

Teil 5: Einen kompletten CRUD-Workflow bauen​

Aufgabe 6 — Alles in einem Workflow​

Jetzt kombinierst du das Gelernte. Baue einen Workflow, der alle Schritte hintereinander ausführt:

[ Web Form Agent ]  →  [ Post Agent (POST) ]  →  [ Post Agent (GET) ]  →  [ Human Task Agent ]
  Eingabe: Name,         Kontakt anlegen        Angelegten Kontakt       Ergebnis prüfen
  Firma, E-Mail                                  per ID abrufen

Die Herausforderung: Der zweite Post Agent (GET) muss die id verwenden, die der erste Post Agent (POST) in seiner Antwort zurückgegeben hat.

Überlege:

  • Wie greifst du auf die id aus der Antwort des ersten Post Agents zu?
  • Welchen output_mode brauchst du beim ersten Post Agent, damit die Antwortdaten in der Nachricht verfügbar sind?
  • Brauchst du einen JSON Parse Agent zwischen den beiden Post Agents?
Tipp anzeigen

Setze beim ersten Post Agent output_mode auf "merge" und aktiviere parse_response_json, damit die Antwort als strukturiertes Objekt in der Nachricht landet. Dann kannst du im zweiten Post Agent auf {{ body.id }} zugreifen — oder, falls nötig, schalte einen JSON Parse Agent dazwischen der den body-String in ein Objekt umwandelt.

Reflexion​

Du hast jetzt jeden der fünf grundlegenden API-Endpunkte mit dem Post Agent in 42°OS angesprochen. Halte für dich fest:

HTTP-MethodePost Agent methodWas sie tutTypischer Status-Code
GET (Liste)get
GET (einzeln)get
POSTpost
PUTput
DELETEdelete

Diese Muster sind bei fast jeder REST API identisch. Wenn du eine neue API anbinden musst, ändern sich URL, Payload und ggf. die Authentifizierung — aber die Grundstruktur des Post Agents bleibt dieselbe.

Weiter: Einheit 15 — Debugging-Strategie